home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group01b.txt
/
000090_icon-group-sender_Thu Jul 5 08:59:40 2001.msg
< prev
next >
Wrap
Internet Message Format
|
2002-01-03
|
3KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id f65FxDw19347
for icon-group-addresses; Thu, 5 Jul 2001 08:59:13 -0700 (MST)
Message-Id: <200107051559.f65FxDw19347@baskerville.CS.Arizona.EDU>
From: Chris.D.Tenaglia@jci.com
Subject: Re: Software testing for Icon?
To: art.eschenlauer@sufsys.com
Cc: icon-group@cs.arizona.edu
Date: Thu, 5 Jul 2001 09:06:57 -0500
X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls(Release 5.0.6a
|January 17, 2001) at 07/05/2001 09:25:08 AM
Errors-To: icon-group-errors@cs.arizona.edu
Status: RO
Content-Length: 2353
This is probably because the variables are not typed. The data
in the variables and the operation on the variables indicates the
type.
procedure example(arg1,arg2,arg3)
arg1, arg2, and arg3 could be any type. The emphasis shifts from
the compiler to programmer. But this issue has never surfaced in companies
I've been at. Their usual anti-icon argument is that it's not supported
by Sun, HP, or Compaq in our software support contracts. So we're locked
into VMS DCL or Posix shell script. I can justify icon in rare cases when
a scripting solution becomes huge and convoluted, or using Xwindows,
or it implements much better with set() algorythms.
Chris Tenaglia, technical analyst, Johnson Controls
art.eschenlauer@
sufsys.com To: icon-group@CS.Arizona.EDU
cc:
06/25/01 11:33 Subject: Software testing for Icon?
AM
One concern that I expect people to raise with respect to using Icon in the
"mainstream" is, "Icon cannot be trusted because it does not typecheck
arguments at compile time. How can you protect against programmer errors
in
the arguments passed during infrequently-executed invocations?" I don't
think that the response (however true) that C++ has compile-time
type-checking and yet still is notorious for null pointer errors, etc, will
convince anybody.
This raises two questions in my mind regarding Icon:
1. Should one adopt a "defensive programming style", always checking the
arguments passed to each routine?
2. What work has been done on developing rigorous software-testing
methodology for Icon programs?